Understanding Server-Side Request Forgery (SSRF)
What is SSRF?
Server-Side Request Forgery occurs when an attacker manipulates a vulnerable web application to make HTTP requests to an unintended destination. These requests originate from the server itself, allowing attackers to access internal resources that are typically inaccessible externally.
How SSRF Works
- Vulnerable Feature: The application accepts user-supplied URLs for resources like images, data feeds, or webhooks.
- Attacker Input: The attacker submits a malicious URL targeting internal resources, loopback addresses (127.0.0.1), or private IP ranges.
- Server Executes: The server initiates the request, bypassing external network restrictions and firewall rules.
- Information Leak/Action: The server's response may include sensitive internal data or enable further actions against internal services.
Common SSRF Targets
- Cloud Metadata Services: AWS, Azure, and Google Cloud metadata endpoints can expose temporary credentials (e.g., AWS 169.254.169.254).
- Local System Files: Using file:// or other URL schemes to access server configuration or sensitive files.
- Internal Services: Admin interfaces, internal REST APIs, or HTTP-enabled databases accessible only internally.
- Internal Port Scanning: Determine open ports on internal hosts by analyzing responses to SSRF requests.
Common SSRF Attack Payloads
- Targeting Local Server:
http://127.0.0.1/admin or obfuscated IP like http://2130706433/.
- Accessing Cloud Metadata: AWS EC2
http://169.254.169.254/latest/meta-data/iam/security-credentials/ROLE_NAME to steal temporary IAM credentials.
- Local File Inclusion:
file:///etc/passwd or dict://localhost:6379 to read sensitive files or interact with local services.
Mitigation Strategies
- Allow List: Permit only specific hosts, protocols, and ports. Reject all others by default.
- Input Validation: Strictly validate URLs and schemes (only https/http), avoiding reliance on IP blacklists.
- Disable Unused URL Schemes: Prevent risky protocols like file://, gopher://, ftp://, dict://.
- Restrict Response Handling: Never return raw server responses directly to users; sanitize data first.
- Disable Redirections: Do not follow HTTP redirects automatically to prevent bypassing allow lists.
- Network Segmentation: Isolate servers making outbound requests, enforce firewall rules, and apply least privilege principles.
Securing AWS Against SSRF
Implement Instance Metadata Service Version 2 (IMDSv2) to mitigate SSRF risks:
- Step 1: Get Token (PUT Request):
PUT /latest/api/token with header X-aws-ec2-metadata-token-ttl-seconds.
- Step 2: Access Metadata (GET Request):
GET /latest/meta-data/iam/security-credentials/ with header X-aws-ec2-metadata-token containing the token from Step 1.
This prevents simple SSRF GET attacks by requiring a session-based token, making exploitation significantly harder.
- Enforce IMDSv2: Require all EC2 instances to use IMDSv2.
- Network Controls: Block all unnecessary outbound traffic to private IP ranges, including metadata service addresses.
- Use Workload Identity: Prefer IAM roles for service accounts (IRSA) for containers to separate credentials from instance network paths.
Key Takeaway
SSRF is a high-risk vulnerability that can expose internal resources and cloud credentials. Proper input validation, strict allow lists, network segmentation, and cloud-specific protections like IMDSv2 are essential for defense-in-depth against SSRF attacks.